The Elephant in the Room. Lessons (we should have already learned) from the GOP Data Leak

Yesterday it was revealed that personally identifiable information (PII) for roughly 61 percent of the US population was leaked by a marketing firm contracted by the Republican National Committee. Were state-sponsored attackers involved? Is this some strange twist to the DNC hack to appear bipartisan? (insert suspenseful crescendo here!)

No. This is a whole lot simpler than that. This is, in fact, as basic as it gets. As it turns out, the marketing firm created a database in Amazon where they stored a ton (roughly 25 terabytes) of super secret stuff. And, as we’ve found out, this server was exposed publicly and they forgot to protect it with a password. Ouch.

As reported by Gizmodo, home addresses, birthdates, phone numbers, and a slew of information about voters’ tendencies when it comes to hot-button issues like gun ownership, stem cell research, abortion, and potentially religious affiliation and ethnicity were exposed.

Something I can’t help but reflect back on is a conversation I had recently with a well-known Gartner analyst covering the CASB space who said, “before I ever start talking with folks about any security tools, CASBs included, I ask them if they’ve got the basics covered, like IAM, proper privileged account precautions, and so on. Because if they can’t look me in the eye and say they’ve got that covered, then what’s the point of going after the emerging stuff? It’s like installing sophisticated surveillance in your home before you make sure your doors have locks.”

I couldn’t agree more.

Of course this isn’t all as cut and dried as I’m making it out to be. Things move fast. The way people work has changed and so has the way that we find, provision, and deprovision the services our people use. I can click two buttons and instantly integrate two cloud services together, and I never lifted a pixel towards my IT department for permission. Everything is “agile” now, and an innocent “test” instance can suddenly become your “production” instance in the blink of an eye. A database in AWS, for example, can suddenly become larger than 25 terabytes and contain data from Karl Rove’s super PAC. Could have easily been Azure or GCP since the average enterprise is using 4 or more IaaS services – but who’s counting. The reality is that somewhere at the end of a very heated call from the RNC is someone who “just forgot,” or “thought it had already been done,” or “didn’t check the permissions/exposure to know the data was exposed.” And yet how many of us would swear up and down that we are absolutely certain our teams would have enough working knowledge of the tools, combined with the right checks and balances to ensure this won’t happen to us? Not many of us, I think.

Of course I’m delighted to work at a place that has ways to help you avoid an embarrassing situation like this. I’m also happy that Netskope has built this in a way that scales with the business, personnel changes, growth, and new challenges. Some of that is purely our technical advantage from a cloud security point of view and you can read more about that in the “Security Evolved” section of our website. In other cases, it’s a blend of the technology and practical knowledge gained through hundreds of CASB deployments. To be more specific, our Cloud Security Triage Process provides a practical approach to governing cloud services in four steps. At a high-level, you need to be able to safely sanction and safely permit certain unsanctioned cloud services with granular controls and handle things at a category level. Imagine if there had been a policy in place that examined permissions / access control for any AWS database being created and then prevented upload of sensitive data from any database exposed to the public without a password. That’d be pretty great, right? If might even make it ok if that elephant forgets a few things every now and then – even some of the basics.